Unit for communication by means of a predetermined protocol

ABSTRACT

The invention relates to a unit (SYST) for communication by means of a predetermined protocol, said communication unit (SYST) including: a master device (EQ_MAI); and a slave device (EQU_ESC) capable of communicating with a vehicle according to a UHF or BF protocol, and capable of assuming a plurality of states, characterized in that the master device (EQ_MAI) is suitable for sending, to the slave device (EQU_ESC), alerts pertaining to the actuation of a state.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to a communication unit based on adetermined protocol. The technical field of the invention is, in ageneral manner, that of the communications between a master entity and aslave entity, and more particularly that of the communications between avehicle remote control electronic key and an intelligent mobiletelephone (or “smartphone”).

TECHNOLOGICAL BACKGROUND OF THE INVENTION

Vehicle remote control electronic keys have been known for severalyears. In a known manner, certain keys possess a listening mode in whicha key is able to receive information transmitted by a vehicle, by UltraHigh Frequency (UHF) or Low Frequency (LF) link. The informationindicates for example that a door of the vehicle has been forced, that atire has burst, or that a window pane has been broken. When an item ofinformation is received by the key, the key can signal same for exampleby emitting a noise.

Moreover, some of these keys are also able to transmit the informationfrom the vehicle to a master entity of smartphone, PDA, or laptopcomputer type. Communication between the key and the master entity isconventionally performed by bluetooth protocol, by bluetooth low energyprotocol, or by NFC protocol.

Conventionally, a vehicle key having a bluetooth or bluetooth low energycomponent, and able to communicate with a master entity, is able to takethree states:

-   -   idle, in which the key neither receives nor emits signals, and        is not connected to any other entity;    -   discoverable, in which the key periodically emits presence        messages;    -   connected, in which the key is connected to the master entity.

To exchange information, the key must be in the connected state. Priorto connection, the key must have been initially pinpointed by the masterentity via the presence signals emitted in the discoverable state. Thus,to be able to communicate with the smartphone, the discoverable andconnected states are invoked often, since the key must remain in thediscoverable or connected state when the user needs it.

Now, the discoverable state, the connected state and the listening modeconsume energy, thereby considerably reducing the lifetime of thebattery of the key.

GENERAL DESCRIPTION OF THE INVENTION

The subject of the invention offers a solution to the problem which hasjust been set forth, by proposing a solution making it possible toconserve the battery of the key.

According to a first aspect, the invention therefore relates essentiallyto a communication unit based on a determined protocol, saidcommunication unit comprising:

-   -   a master entity;    -   a slave entity able to communicate with a vehicle according to a        UHF or LF protocol, and able to take several states;

characterized in that the master entity is adapted for dispatchingalarms for activating at least one state to the slave entity.

By virtue of the definition of the activation alarms, the states of theslave entity are automatically adapted to the needs of the user of themaster entity. The various energy-consuming states are thus not usedmore than necessary.

In addition to the main characteristics which have just been mentionedin the previous paragraph, the communication unit according to theinvention can exhibit one or more complementary characteristics fromamong the following, considered individually or according to thetechnically possible combinations:

-   -   the master entity and the slave entity are able to communicate        by bluetooth protocol or by bluetooth low energy (BLE) protocol.    -   the slave entity is able to take the following states:    -   idle, in which the slave entity neither receives nor emits        signals, and is not connected to any entity;    -   discoverable, in which the slave entity periodically emits        presence signals;    -   connected, in which the slave entity is connected to the master        entity,    -   listening mode, in which the slave entity is able to receive        signals from the vehicle by UHF or LF protocol,

and in that the states activated by the activation alarms are:

-   -   the idle state,    -   the discoverable state,    -   the listening mode state.    -   when the slave entity is in the connected state, the master        entity is able to dispatch to it a duration cue whose value        corresponds to the duration of activation of said state of the        slave entity.    -   when the slave entity is in the connected state, the master        entity is able to dispatch alarms to it for deactivating said        state of the slave entity.    -   the slave entity comprises an inertial wakeup device able to        switch the slave entity from the idle state to the discoverable        state.    -   the master entity and the slave entity are able to communicate        by NFC protocol.

According to the nonlimiting embodiment of NFC communication, innonlimiting embodiments:

-   -   the state activated by the activation alarms is a listening mode        state in which the slave entity is able to receive signals from        the vehicle by UHF or LF protocol.    -   the master entity is able to dispatch to the slave entity a        duration cue whose value corresponds to the duration for which        the slave entity must remain in the listening mode state.    -   the master entity is able to dispatch to the slave entity alarms        for deactivating the listening mode state.    -   the master entity is able to dispatch a cue for clock        synchronization to the slave entity.    -   the master entity is able to dispatch a cue for clock        synchronization to the slave entity.    -   the master entity and the slave entity form a single entity        comprising a man machine interface.    -   the activation alarms are dispatched by means of the man machine        interface.

The invention and its various applications will be better understood onreading the description which follows and on examining the figures whichaccompany it.

BRIEF DESCRIPTION OF THE FIGURES

The figures are presented merely by way of wholly nonlimiting indicationof the invention.

The figures show:

in FIG. 1, a diagram representing a communication unit according to anonlimiting embodiment of the invention;

in FIG. 2, a timing diagram representing exchanges of information withinthe communication unit, according to a nonlimiting embodiment of theinvention;

in FIG. 3, a GATT profile table defining alarms implemented within thecommunication unit, under the BLE protocol, according to a nonlimitingembodiment of the invention; and

in FIG. 4, a GATT profile table defining a listening mode implementedwithin the communication unit, under the BLE protocol, according to anonlimiting embodiment of the invention.

DETAILED DESCRIPTION OF AT LEAST ONE EMBODIMENT OF THE INVENTION

FIG. 1 is a diagram representing a communication unit SYST according toone embodiment of the invention, said communication unit SYSTcomprising:

-   -   a slave entity ENT_SLV    -   a master entity ENT_MAS comprising a man machine interface (MMI)

According to a nonlimiting embodiment of the invention, the slave entityENT_SLV is an electronic key of the vehicle, and the master entityENT_MAS is a smartphone. According to other embodiments of theinvention, the master entity ENT_MAS is a PDA, a laptop computer, etc.

In another embodiment, the master entity ENT_MAS and the slave entityENT_SLV form just a single entity comprising an MMI and capable ofcommunicating with a vehicle. This entity is either the vehicle's remotecontrol key, or the smartphone.

The slave entity ENT_SLV comprises an RF transmitter/receiver R_RF, andhas a listening mode state, also called the vehicle monitoring mode, inwhich it is able to receive information from the vehicle via the RFtransmitter/receiver R_RF, by UHF or LF protocol.

In a nonlimiting embodiment, the master entity ENT_MAS and the slaveentity ENT_SLV communicate by NFC protocol. Provision may also be madeto configure the slave entity ENT_SLV so as to lock/unlock theautomotive vehicle contactlessly (“Remote Keyless Entry” or RKE), suchas the locking/unlocking of the vehicle's central locking system, bysimply bringing the slave entity ENT_SLV close to the vehicle forcommunication according to the NFC protocol.

The NFC protocol is a short-range wireless link, with a range of theorder of a few centimeters, which uses a data exchange protocol based onradio frequencies of very short range. This is an extension of theradio-identification techniques which, while being based on the ISO/IEC14443 standard, allows communication between peripherals in peer-to-peermode. The NFC protocol is based on inductive coupling and loadmodulation at the level of a slave apparatus.

NFC technology is currently being developed by an industrial consortiumgrouped under the name NFC Forum. NFC technology is derived from RFID(Radio Frequency Identification) technology and uses NFC processors orcomponents exhibiting several operating modes, especially a reader modeand a card emulation mode.

In reader mode, an NFC processor operates as a conventional RFID readerfor read-access or write-access to an RFID chip. The NFC processor emitsa magnetic field, dispatches data by modulation of the amplitude of themagnetic field and receives data by load modulation and inductivecoupling. This mode is also referred to as active mode since the NFCprocessor emits a magnetic field in this mode.

In the emulation mode, an NFC processor operates in a passive fashion inthe manner of a transponder in order to dialog with another reader andbe seen by the other reader as an RFID chip. The processor does not emitany magnetic field, receives data by demodulating a magnetic fieldemitted by the other reader and emits data by modulation of theimpedance of its antenna circuit (load modulation). This mode is alsoreferred to as passive mode, since the NFC processor does not emit anymagnetic field in this mode.

Other modes of communication can be implemented, especially a so-called“device” mode where a component must pair with another NFC processor inthe same operating mode, each NFC processor places itself alternately ina passive state (no field emission) to receive data and in an activestate (with field emission) to emit data.

In these three operating modes, an NFC processor can implement severalcontactless communication protocols for example ISO 14443-A, ISO 14443-Bor ISO 15693. Each protocol defines a frequency of emission of themagnetic field, a procedure for modulating the amplitude of the magneticfield to emit data in active mode, and a procedure for load modulationby inductive coupling to emit data in passive mode.

A certain number of standards define the NFC protocol:

-   -   NFCIP-1 (ISO/IEC 18092) defines the interface and the        communication protocol between two NFC peripherals;    -   ISO/IEC 14443-1 to ISO/IEC 14443-4 define the communication with        contactless integrated circuits;    -   NDEF (NFC Data Exchange Format) defines the logical exchange        format for data.

NFC communication generally exhibits the following characteristics:

-   -   Communication bitrates: 106, 212, 424 or 848 kbit/s;    -   Frequency range: 13.56 MHz;    -   Communication distance: about 10 cm;    -   Communication mode: half-duplex or full-duplex.

In this embodiment, the slave entity ENT_SLV comprises an NFC (NearField Communication) component, and is able to take two states:

-   -   a passive state (also called reader mode) in which the NFC        component emits a magnetic field, dispatches data by modulation        of the amplitude of the magnetic field and receives data by load        modulation and inductive coupling;    -   an active state (also called emulation mode) in which the NFC        component does not emit any magnetic field, receives data by        demodulating a magnetic field emitted by another reader and        emits data by modulation of the impedance of its antenna circuit        (load modulation).

In another nonlimiting embodiment, the slave entity ENT_SLV comprises abluetooth or bluetooth low energy component R_B, and is able to takethree states:

-   -   idle, in which the slave entity ENT_SLV neither receives nor        emits signals, and is not connected to any entity;    -   discoverable (or advertising), in which the slave entity ENT_SLV        periodically emits presence messages;    -   connected, in which the slave entity ENT_SLV is connected to the        master entity ENT_MAS.

The master entity ENT_MAS can also take several states:

-   -   idle, in which the master entity ENT_MAS neither receives nor        emits signals, and is not connected to any other entity;    -   scanning, in which the master entity ENT_MAS searches for the        presence signals, emitted by a slave entity ENT_SLV when the        latter is in the discoverable mode;    -   initiating, in which the master entity ENT_MAS is able to        establish a connection with the slave entity ENT_SLV when the        latter is in the discoverable mode;    -   connected, in which the master entity ENT_MAS is connected to        the slave entity ENTSLV.

When the master entity ENT_MAS and the slave entity ENT_SLV areconnected, the master entity ENT_MAS is able to dispatch alarms to theslave entity ENT_SLV for activating a state (the discoverable state andthe idle state of the slave entity ENT_SLV, in the case of bluetooth orbluetooth low energy). Moreover, the master entity ENT_MAS is able todispatch alarms to the slave entity ENT_SLV for activating anddeactivating the listening mode state (whether in the case of bluetoothor bluetooth low energy or NFC). It will be noted that the master entityENT_MAS is able to dispatch alarms for activating several states at atime.

By “alarm for activating a state”, also called rendezvous, is meant avalue of time of activation of the state. Thus, the user of the masterentity can set time spans for automatic vehicle idling and monitoring.

In another nonlimiting embodiment of the invention, the master entityENT_MAS is able to dispatch alarms for activating the listening modestate and a duration cue (or “timer”) corresponding to the duration forwhich the slave entity ENT_SLV must remain in the listening mode state.These activation and/or deactivation alarms, and/or this duration cue,make it possible to define time spans of activation of states. In anonlimiting embodiment of the invention, the alarms for activatingand/or for deactivating states, and/or the duration cue, are determinedby the user of the master entity ENT_MAS.

Moreover, the master entity ENT_MAS is able to dispatch a clocksynchronization cue to the slave entity ENT_SLV.

In a particular embodiment, when the master entity ENT_MAS and the slaveentity ENT_SLV are connected and an alarm for activating the idle stateis triggered, it is preferable to wait for the connection between themaster entity ENT_MAS and the slave entity ENT_SLV to terminate beforeeffecting the idling of the slave entity ENT_SLV. Indeed the user doesnot wish to see his slave entity ENT_SLV become idle while busy carryingout operations. In this precise case and subsequent to intentional orunintentional disconnection (out of range), the slave entity ENT_SLVwill not switch from the connected state to the discoverable state, andfrom the discoverable state to the idle state, but it will switchdirectly from the connected state to the idle state.

In an alternative, the user will be able to be informed on his slaveentity ENT_SLV that the setting to idle alarm has just been triggered.He will then be able to grant or otherwise authorization for the slaveentity ENT_SLV to be set to idle by forcing disconnection of the masterentity ENT_MAS. These operations occur by way of messages or pop-ups onthe screen of the slave entity ENT_SLV and by response action of theuser on the slave entity ENT_SLV (pressing of buttons or pressing on anarea of the touchscreen).

In a second alternative which favors energy economy, the slave entityENT_SLV will switch from the connected state to the idle stateimmediately upon the triggering of an alarm for activating the idlestate without request for confirmation of the user.

FIG. 2 is a timing diagram representing exchanges of information betweenthe master entity ENT_MAS and the slave entity ENT_SLV, according to anonlimiting embodiment of the invention in which the master entityENT_MAS and the slave entity ENT_SLV communicate by Bluetooth orBluetooth Low Energy (BLE) protocol. In the Bluetooth protocol, thealarms are defined according to the communication specifications of theBluetooth standard. In the example illustrated:

-   -   from step 1 to step 9, an illustration of the dispatching and        the use of an alarm for activating the discoverable state        alarm_dis and an alarm for activating the idle state alarm_idle.    -   from step 10 to step 17, an illustration of the dispatching and        of the use of an alarm for activating the listening mode state        alarm_li and an alarm for deactivating the listening mode state        alarm_deli, and an illustration of a case in which there is a        vehicle intrusion.

Step 1: The slave entity ENT_SLV is in the discoverable state, ittherefore periodically emits signals of presence sigpres. The masterentity ENT_MAS is in the idle state.

Step 2: A user of the master entity ENT_MAS triggers the scanning modeof said master entity ENT_MAS. The master entity ENT_MAS then detectsthe signals of presence sig_pres of the slave entity ENT_SLV. Havingdetected the signals of presence sig_pres of the slave entity ENT_SLV,the master entity ENT_MAS automatically switches to the initiationstate, and dispatches a connection request conn_req to the slave entityENT_SLV.

Step 3: The connection between the master entity ENT_MAS and the slaveentity ENT_SLV is established after a connection establishment requestconn_est triggered by the user, directly or by pre-configuration.

Step 4: The master entity ENT_MAS and the slave entity ENT_SLV areconnected to one another and exchange data data_exch. The master entityENT_MAS dispatches the clock synchronization cues clock_sync as well asthe alarm for activating the discoverable state alarm_dis and the alarmfor activating the idle state alarm_idle, to the slave entity ENT_SLV. Aclock synchronization sync between the slave entity ENT_SLV and themaster entity ENT_MAS is performed. Next the master entity ENT_MASdisconnects from the slave entity ENT_SLV through a disconnectionrequest disc_req.

Step 5: The master entity ENT_MAS and the slave entity ENT_SLV thenswitch to the idle state. The battery of the slave entity ENT_SLV isthen conserved. Next the alarm for activating the discoverable statealarm_dis is triggered at the preset time.

Step 6: The slave entity ENT_SLV then automatically switches to thediscoverable state. Simultaneously, the master entity ENT_MAS switchesto the initiation state and dispatches a connection request conn_req tothe slave entity ENT_SLV. The connection between the master entityENT_MAS and the slave entity ENT_SLV is established after a connectionestablishment request conn_est accepted by the slave entity ENT_SLV.

Step 7: The master entity ENT_MAS and the slave entity ENT_SLV areconnected to one another and exchange data data_exch. The master entityENT_MAS dispatches the clock synchronization cues clock_sync to theslave entity ENT_SLV. A clock synchronization sync between the slaveentity ENT_SLV and the master entity ENT_MAS is performed again. Nextthere is unintentional loss of connection.

Step 8: The master entity ENT_MAS then switches to the idle state, andthe slave entity ENT_SLV switches back to the discoverable state, sincethe alarm for activating the idle state alarm_idle has not yet beentriggered. The slave entity ENT_SLV periodically dispatches signals ofpresence sig_pres. Next the alarm for activating the idle statealarm_idle is triggered. It will be noted that the master entity may inanother example attempt to connect to the slave entity, but if thelatter is out of range, the slave entity ENT_SLV switches back to thediscoverable state since the alarm for activating the idle statealarm_idle has not yet been triggered.

Step 9: The slave entity ENT_SLV then switches to the idle state. Nextthe alarm for activating the discoverable state alarm_dis is triggered.

Step 10: The slave entity ENT_SLV automatically switches to thediscoverable state. Simultaneously, the master entity ENT_MAS switchesto the initiation state and dispatches a connection request conn_req tothe slave entity ENT_SLV. The connection between the master entityENT_MAS and the slave entity ENT_SLV is established after a connectionestablishment request conn_est.

Step 11: The master entity ENT_MAS and the slave entity ENT_SLV areconnected to one another and exchange data data_exch. The master entityENT_MAS dispatches clock synchronization cues clock_sync and alarms foractivating alarm_li and for deactivating the listening mode alarm_delito the slave entity ENT_SLV. A clock synchronization sync between theslave entity ENT_SLV and the master entity ENT_MAS is performed again.Next the master entity ENT_MAS disconnects from the slave entity ENT_SLVafter a disconnection request disc_req.

Step 12: The master entity ENT_MAS switches to the disconnected state,and the slave entity ENT_SLV switches back to the discoverable state,since the alarm for activating the idle state alarm_idle has not yetbeen triggered. The slave entity ENT_SLV periodically dispatches signalsof presence sig_pres.

Step 13: The user of the master entity ENT_MAS triggers the scanningmode of said master entity ENT_MAS. The master entity ENT_MAS thendetects the signals of presence sig_pres of the slave entity ENT_SLV,the latter being in the discoverable mode.

Step 14: Having detected the signals of presence sig_pres of the slaveentity ENT_SLV, the master entity ENT_MAS automatically switches to theinitiation state, and dispatches a connection request conn_req to theslave entity ENT_SLV. The connection between the master entity ENT_MASand the slave entity ENT_SLV is established subsequent to a connectionestablishment request conn_est.

Step 15: The master entity ENT_MAS and the slave entity ENT_SLV areconnected to one another and exchange data data_exch.

Step 16: The alarm for activating the listening mode state alarm_li istriggered. The slave entity ENT_SLV then switches to the listening modestate. Periodic exchanges may or may not be made between the masterentity ENT_MAS and the slave entity ENT_SLV to monitor the properoperation of the listening mode. At a given moment, the vehicledispatches an intrusion cue intr to the slave entity ENT_SLV. The slaveentity ENT_SLV then automatically dispatches an intrusion notificationnotif_intr to the master entity ENT_MAS.

Step 17: The alarm for deactivating the listening mode alarm_deli istriggered. The slave entity ENT_SLV leaves the listening mode state.

In the other embodiment of the invention where a duration cue is used inplace of the alarm for deactivating the listening mode state alarm_deli,the slave entity ENT_SLV leaves the listening mode state when the timeelapsed from the instantaneous activation (namely the triggering of theactivation alarm) of the listening mode state alarm_li is equal to theduration corresponding to the duration cue. Indeed the duration cuecorresponds to the duration for which the slave entity ENT_SLV is in thelistening mode.

In another embodiment of the invention, the slave entity ENT_SLVcomprises an inertial wakeup device able to switch the slave entityENT_SLV from the idle state to the discoverable state. It is noted thatthe slave entity ENT_SLV may have a state called the super_idle state,which corresponds to the idle state with which is associated anothercharacteristic: the internal clock of the slave entity ENT_SLV isdeactivated. In the case where the slave entity has a super_idle state,the inertial wakeup device is also able to switch the slave entityENT_SLV from the super_idle state to the discoverable state. Theinertial wakeup device is for example an accelerometer, a very lowconsumption inertial sensor or a passive mechanical breaker withunbalance mass.

In the Bluetooth Low Energy (BLE) protocol, in a nonlimiting embodiment,the alarms are defined according to a table of attributes, dubbed theGATT (Generic Attribute Table) profile table, a nonlimiting example ofwhich is represented in FIG. 3. This table relates solely to the BLEprotocol, in the other embodiments of the invention, the alarms areimplemented according to the communication specifications of thebluetooth or NFC standards. The GATT table is created in the slaveentity ENT_SLV during its manufacture, and is able to be used (readand/or modified) by the master entity ENT_MAS.

Each row of the table corresponds to an attribute. The table comprises 4columns:

-   -   an Address column, dubbed “Handle” according to the BLE        protocol, corresponding to the logical address of the attribute        in the table. The address is given in hexadecimal and in        decimal;    -   a Type column, indicating the type of the attribute. The type is        given by a value in hexadecimal and by a name.    -   a Value column, indicating the value of the attribute;    -   a Permissions column, indicating whether and how the master        entity ENT_MAS may have access to the value of the attribute.

The table is divided into services. FIG. 3 illustrates a first servicestarting at row 1 and terminating at row 14. Each service is dividedinto characteristics. In the example represented, the first servicecomprises 4 characteristics: a first characteristic starts at row 2 andterminates at row 5; a second characteristic starts at row 6 andterminates 8, a third characteristic starts at row 9 and terminates atrow 11, and a fourth characteristic starts at row 12 and terminates atrow 14.

The attribute of row 1 corresponds to the declaration of the start ofthe first service. The type of a service start declaration attribute is0x2800. The value of a service start declaration attribute is coded on 2bytes. Here the value is 0xFE00, this being coded by 00:FE. The masterentity ENT_MAS can only read the service start attribute, not modify it,this being indicated by the permission GATT_PERMIT_READ.

The first characteristic starts at row 2. It terminates at row 5. Thefirst characteristic defines the synchronization clock clock_sync,described previously. Said synchronization clock clock_sync willsubsequently be used to undertake a clock synchronization sync betweenthe master entity ENT_MAS and the slave entity ENT_SLV (a writeresynchronizes the time of the slave entity ENT_SLV, a read or anotification makes it possible to provide the master entity ENT_MAS withthe time of the slave entity ENT_SLV).

The attribute of row 2 corresponds to the declaration of the firstcharacteristic. A characteristic declaration attribute is of type0x2803. The value of a characteristic declaration attribute is coded on5 bytes:

-   -   the first two bytes indicate the type of the characteristic        (here 0xFE01, coded by 01:FE)    -   the following two bytes indicate the address at which the value        of the characteristic is situated (here 0x0011, coded by 11:00,        thus signifying that the value of the characteristic is provided        at the address 0011, that is to say at the third row of the        table)    -   the last byte indicates the permissions of the characteristic        (here 1A). 02 signifies read only, 08 signifies write only, 0A        signifies read and write, 1A signifies read, write and        notifications.

The master entity ENT_MAS can only read the characteristic declarationattribute, not modify it, as indicated by the permissionGATT_PERMIT_READ.

The attribute of row 3 corresponds to the value of the firstcharacteristic. This value is coded on 3 bytes (here 00:00:00). In theexample described, the value corresponds to the clock value for thesynchronization clock_sync, in hours/minutes/seconds (hh:mm:ss). Inanother embodiment, the clock value is coded according to the RFC868protocol that is to say by a number of 32 bits representing the numberof seconds since 00:00:00 (midnight) on the first of January 1900 GMT,the value 1 or 0x00000001 representing 00:00:01 on the first of January1900 GMT. The master entity ENT_MAS can read and modify this value, asindicated by the permission GATT_PERMIT_WRITE|GATT_PERMIT_READ.

The attribute of row 4 corresponds to information for configuring themaster entity ENT_MAS. A configuration attribute has type 0x2902. Thevalue of a configuration attribute is coded on 2 bytes. This valueindicates whether messages of notification type or of indication type,which are defined according to the BLE protocol, are authorized betweenthe master entity ENT_MAS and the slave entity ENT_SLV. The notificationmessages do not require the slave entity ENT_SLV to dispatch anacknowledgment of receipt to the master entity ENT_MAS, incontradistinction to the indication messages. The notifications arecoded by 01, the indications are coded by 02. The master entity ENT_MAScan read and modify this value, as indicated by the permissionGATT_PERMIT_WRITE|GATT_PERMIT_READ.

The attribute of row 5 corresponds to information intended for the userof the master entity ENT_MAS. A user information attribute has type0x2901. In the example described, the value of this attribute is“clock”. Thus, the user of the master entity ENT_MAS will see “clock”displayed on the MMI of the master entity ENT_MAS at the moment of clocksynchronization. The master entity ENT_MAS can only read this attribute,not modify it, as indicated by GATT_PERMIT_READ.

The second characteristic, rows 6 to 8 of the table, defines the alarmfor activating the discoverable state alarm_dis; the thirdcharacteristic, rows 9 to 11 of the table, defines the alarm foractivating the idle state alarm_idle, and the fourth characteristic,rows 12 to 14 of the table, defines the states of the synchronizationclock clock_sync, of the alarm for activating the discoverable statealarm_dis, and of the alarm for activating the idle state alarm_idle.The states are indicated by the value of the fourth characteristic: 0signifies that everything is deactivated, 3 signifies that the alarm foractivating the discoverable state alarm_dis is activated, 5 signifiesthat the alarm for activating the idle state alarm_idle is activated,and 7 signifies that both alarms are activated. The second, the thirdand the fourth characteristic are filled in in the same manner as thefirst characteristic.

FIG. 4 illustrates a second service relating to RF listening to thevehicle by the slave entity ENT_SLV. The corresponding table is filledin in the same manner as the table corresponding to the first service.

The writing and the reading of the attributes of the GATT profile tableis done in a known manner by means of writing and reading messages suchas described in the V4 BLE standard p. 1929 and p. 1871.

Thus when the user of the master entity ENT_MAS defines the alarms viathe master entity ENT_MAS, the latter will write the values of thealarms defined by dispatching data packets to the slave entity ENT_SLV.The values will thus be written in the GATT table. The slave entityENT_SLV will thus read the values of the alarms in its table so as toplace itself in the various states described previously. The masterentity ENT_MAS will read the GATT table to display messages on the MMIfor the user.

Of course the description of the invention is not limited to theapplication, to the embodiments and to the examples describedhereinabove.

Thus, in a nonlimiting embodiment, when the master entity ENT_MAS andthe slave entity form just a single entity and this single entity is thevehicle's remote control key, the latter comprises an MMI which, bycombining presses of the key, makes it possible to dispatch the alarmsfor activating a state. Thus, for example, it is possible to perform adouble press for 5 seconds to activate/deactivate an alarm on the buttonnormally used to activate the key, and then several times on the buttonwhich is normally used to lock the vehicle to set theactivation/deactivation hour, and several times on the button normallyused to unlock the vehicle to set the activation/deactivation minutes.In another nonlimiting example, the MMI of the key can be a touchscreen.In another nonlimiting example, the MMI of the key can be a screen (suchas LCD or digit and pictogram matrix, OLED, etc.) associated withbuttons (such as keypad, joystick, numerical pad, etc.).

Of course, the single entity can also be a smartphone which alsocomprises the same type of MMI (whether with or without screen).

The invention claimed is:
 1. A communication unit (SYST) based on adetermined protocol, said communication unit (SYST) comprising: a masterentity (ENT_MAS); a slave entity (ENT_SLV) configured to communicatewith a vehicle according to a UHF or LF protocol, and configured to takeseveral states wherein said master entity (ENT_MAS) and said slaveentity (ENT_SLV) communicate according to Bluetooth, Bluetooth LowEnergy (BLE) or NFC protocol, said slave entity (ENT_SLV) beingconfigured to take, of the several states, the following states from theBluetooth or BLE protocol: an idle state, in which the slave entity(ENT_SLV) neither receives nor emits signals, and is not connected toany entity, a discoverable state, in which the slave entity (ENT_SLV)periodically emits presence signals (sig_pres), and a connected state,in which the slave entity (ENT_SLV) is connected to the master entity(ENT_MAS), said slave entity (ENT_SLV) being configured to take, of theseveral states, the following states from the NFC protocol: anactive/reader state, and a passive/emulation state, said slave entity(ENT_SLV) being further configured to take, of the several states, thefollowing state: a listening mode state, in which the slave entity(ENT_SLV) receives signals from the vehicle by the UHF or LF protocol,wherein when the master entity (ENT_MAS) and the slave entity (ENT_SLV)are connected in the connected state according to the Bluetooth or BLEprotocol, or are connected in the NFC protocol, the master entity(ENT_MAS) dispatches activation alarms that activate the listening modestate of the slave entity (ENT_SLV), wherein each of the activationalarms are a value that sets a time of activation of the listening modestate and a duration for which the slave entity (ENT_SLV) must remain inat least the listening mode state.
 2. The communication unit (SYST) asclaimed in claim 1, wherein when the master entity (ENT_MAS) and theslave entity (ENT_SLV) are connected by the Bluetooth or BLE protocol,the master entity (MAS_ENT) is further configured to dispatch alarms foractivating the idle state or the discoverable state of the slave entity(ENT_SLV).
 3. The communication unit (SYST) as claimed in claim 1,wherein, when the slave entity (ENT_SLV) is in the connected state, themaster entity (ENT_MAS) is configured to dispatch to it a duration cuewhose value corresponds to the duration of activation of the connectedstate of the slave entity (ENT_SLV).
 4. The communication unit (SYST) asclaimed in claim 1, wherein, when the slave entity (ENT_SLV) is in theconnected state, the master entity (ENT_MAS) is configured to dispatchalarms to it for deactivating the connected state of the slave entity(ENT_SLV).
 5. The communication unit (SYST) as claimed in claim 1,wherein the slave entity (ENT_SLV) comprises an inertial wakeup deviceconfigured to switch the slave entity (ENT_SLV) from the idle state tothe discoverable state.
 6. The communication unit (SYST) as claimed inclaim 1, wherein, when the slave entity (ENT_SLV) is connected with themaster entity (ENT_MAS) in the Bluetooth, BLE or NFC protocol, themaster entity (ENT_MAS) is configured to dispatch alarms to it fordeactivating the listening mode state.
 7. The communication unit (SYST)as claimed in claim 1, wherein the master entity (ENT_MAS) is configuredto dispatch a cue for clock synchronization (clock_sync) to the slaveentity (ENT_SLV).
 8. The communication unit (SYST) as claimed in claim1, wherein the master entity (ENT_MAS) is an intelligent mobiletelephone, and the slave entity (ENT_SLV) is a vehicle remote controlelectronic key.